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Practitioner's Docket No. _ 



944-001.008 



Preliminary Classification: 
Proposed Class: 
Subclass: 

NOTE: "All applicants are requested to include a preliminary classification on newly filed patent 

applications. The preliminary classification, preferably class and subclass designations, should be 
identified in the upper right-hand comer of the letter of transmittal accompanying the application 
papers, for example 'Proposed Class 2, subclass 129.'" M.P.E.P. § 601, 7th ed. 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

Box Patent Application 

Assistant Commissioner for Patents 

Washington, D.C. 20231 

NEW APPLICATION TRANSMITTAL 



Transmitted herewith for filing is the patent application of 

lnventor(s): SUUMAKI , Hans KALLIO and Kalle AHMAVAARA 

WARNING: 37 C.F.R. § 1.41(a}(1j points out 

"(a) A patent is applied for in the name or names of the actual inventor or inventors. 

"(1) The inventorship of a naiprovisional application is that inventorship set forth in the oath or 
declaration as prescribed by § 1.63, except as provided for in § 1.53(d)(4} and § 1.63(d). If an 
oath or declaration as prescribed by § 1.63 is not filed during the pendency of a nonprovisional 
application, the inventorship is that inventorship set forth in the application papers filed pursuant 
to § 1.53(b), unless a petition under this paragraph accompanied by the fee set forth in § 1.1 7(i) 
is filed supplying or changing the name or names of the inventor or inventors." 

For (title): Transfer of Optimization Algotifchm Parameters During 
Handover of a Mobile Station Between Radio Network 
Subsystems 

CERTIFICATION UNDER 37 C.F.R. § 1.10* 

(Express Mail label number is mandatory.) 
(Express Mail certification is optional.) 

I hereby certify that this New Application Transmittal and the documents refen^ed to as attached therein are tieing 

deposited with the United States Postal Service on this date Nov. 20 , 2000 , in an envelope 

as "Express Mail Post Office to Addressee," mailing Label Number -EL._6..28 637054 US , ad- 

0 the: Assistant Commissioner for Patents. Washington, D.C. 20231. 

Margery B. Hood 



[type or print name of person mailing paper) 




Signature of pa^on m^ifing paper 
WARNING: Certificate of mailing (first class) or facsimile transmission procetmres of 37 C.F.R. §1.8 cannot be 

used to obtain a date of mailing or transmission for this correspondence. 
^WARNING: Each paper or fee filed by "Express Mail' must have the numtier of the "Express Mail" mailing label 
placed thereon prior to mailing. 37 C.F.R. § 1.10(b). 

"Since the filing of correspondence under § 1.10 without the Express Mail mailing lat>el thereon 
is an oversight that can be avoided by the exerdse of reasonable care, requests for waiver of this 
requirement will not be granted on petition. " Notice of Oct. 24, 1996, 60 Fed. Reg. 56,439, at 56.442. 
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1. Type of Application 

This new application is for a(n) 

(check one applicable item below) 
Original (non provisional) 

□ Design 
□ Plant 

WARNING: Do not use this transmittal for a completion in the U.S. of an Intematior^ai Application under 35 
U.S.C. § 371(c}(4), unless the Interrjational Application is tieing filed as a divisional, continuation 
or continuation-in-part application. 

WARNING: Do not use this transmittal for the filing of a provision^ application. 

NOTE: If one of the following 3 items apply, then complete and attach ADDED PAGES FOR NEW APPLICA TION 
TRANSMITTAL WHERE BENEFIT OF A PRIOR U.S. APPLICATION CLAIMED and a NOTIFICATION 
IN PARENT APPLICATION OF THE FILING OF THIS CONVNUATION APPLICATION. 

□ Divisional. 

□ Continuation. 

□ Continuation-in-part (C-l-P). 

2. Benefit of Prior U.S. Application(s) (35 U.S.C. §§ 119(e), 120, or 121) 

NOTE: A nonprovisional application may claim an invention disclosed in one or more prior filed copending 
nonprovisional applications or copending international applications designating the United States of 
America. In order for a nonprovisional application to claim the txnefit of a prior filed copending 
nonprovisional application or copending international application designating the United States of 
America, each prior application must name as an inventor at least one inventor named in the later filed 
nonprovisional application and disclose the named inventor's invention claimed in at least one claim 
of the later filed nonprovisional application in the manner provided by the first paragraph of 35 U.S. C. 
§ 112. Each prior application must also be: 

(i) An international application entitled to a filing date in accordance with PCT Article 1 1 and 
designating the United States of America; or 

(ii) Complete as set forth in § 1.51(b); or 

(iii) Entitled to a filing date as set forth in § 1.53(b) or § 1.53(d) and include the basic filing fee set 
forth in § 1. 16; or 

(iv) Entitled to a filing date as set forth in § 1.530:)) and have paid therein the processtng and retention 
fee set forth in § 1.21(1) within the time period set forth in § 1.53(f). 

37 C.F.R. § 1.78(a)(1). 

NOTE: If the new application being transmitted is a divisional, continuation or a continuation-in-part of a parent 
case, or where the parent case is an International Application which designated the U.S.. or benefit 
of a prior provisional application is claimed, then check the following item and complete and attach 
ADDED PAGES FOR NEW APPLICATION TRMISMITTAL WHERE BENEFTT OF PRIOR U.S. APPLICA- 
TION'S) CLAIMED. 

WARNING: If an application claims the beneTit of the filing date of an earlier filed application under 35 U.S. C. 

§§ 120, 121 or 365(c), the 20-year term of that application will be based upon the filing date of 
the eariiest U.S. application that the application makes reference to under 35 U.S.C. §§ 120, 121 
or 36S(c). (35 U.S.C. § 154(a)(2) does not take into account, for the detenvination of the patent 
term, any application on which priority is claimed under 35 U.S.C. §§ 1 19, 365(a) or 365(b).) For 
a c-i-p application, applicant should review whether any claim in the patent that will issue is 
supported by an earlier application and, if not, the applicant should consider canceling the reference 
to the eariier filed application. The term of a patent is not teased on a claim-by-claim approach. 
See Notice of April 14, 1995, 60 Fed. Reg. 20.195. at 20.205. 
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WARNING: When the last day of pendency of a provision^ application falls on a Saturday. Sunday, or Federal 
holiday within the District of Columbia, any nonprovisional application claiming benefif of the 
provisional application must be filed prior to the Saturday. Sunday, or Federal holiday within the 
District of Columbia. See 37 C.F.R. § 1.78(a)<3). 
The new application being transmitted claims the benefit of prior U.S. applica- 
tion(s). Enclosed are ADDED PAGES FOR NEW APPLICATION TRANSMITTAL 
WHERE BENEFIT OF PRIOR U.S. APPLICATION{S) CLAIMED. 
3. Papers Enclosed 
A. Required for filing date under 37 C.F.R. § 1.53(b) (Regular) or 37 C.F.R. § 1.153 
(Design) Application 
Pages of specification 
^ Pages of claims 
Sheets of drawing 

WAPtNING: DO NOT submit original drawings. A high quality copy of the drawings should be supplied when 
filing a patent application. The drawings that are submitted to the Office must be on strong, white, 
smooth, and non-shiny paper and meet the standards according to § 1.84. If corrections to the 
drawings are necessary, they should be made to the original drawing and a high-quality copy of 
the corrected original drawing then submitted to the Office. Only one copy is required or desired. 
For comments on proposed then-new 37 C.F.R. § 1.84, see Notice of March 9, 1988 (1990 O.G. 
57-62). 

NOTE: "Identifying indicia, if provided, should include the application number or the title of the invention, 
inventor's name, docket number (if any), and the name and telephone number of a person to call if 
the Office is unable to match the drawings to the proper application. This information should be placed 
on the back of each sheet of drawing a minimum distance of 1.5 cm. (5/8 inch) down from the top 
of the page ...» 37 C.F.R. § 1.84(c)). 

(complete the following, if applicable) 

□ The enclosed drawing{s) are photograph(s), and there is also attached a 
"PETITION TO ACCEPT PHOTOGRAPH(S) AS DRAWING(S)." 37 C.F.R. 
§ 1.84(b). 

formal 

□ informal 

B. Other Papers Enclosed 

Pages of declaration and power of attorney 

_L Pages of abstract 

Other 

4. Additional papers enclosed 

□ Amendment to claims 

□ Cancel in this applications claims __ before 

calculating the filing fee. (At least one original independent claim must be 
retained for filing purposes.) 

□ Add the claims shown on the attached amendment. (Claims added have 
been numbered consecutively following the highest numbered original 
claims.) 

□ Preliminary Amendment 

□ Information Disclosure Statement (37 C.F.R. § 1.98) 

□ Form PTO-1449 (PTO/SB/08A and 08B) 

□ Citations 
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□ Declaration of Biological Deposit 

□ Submission of "Sequence Listing," computer readable copy and/or amendment 
pertaining thereto for biotechnology invention containing nucleotide and/or 
amino acid sequence. 

□ Authorization of Attomey(s) to Accept and Follow Instructions from Representa- 
tive 

□ Special Comments 

□ Other 

5. Declaration or oath (including power of attorney) 

NOTE: A newly executed declaration is not required in a continuation or divisional application provided that 
the prior nonprovisional application contained a declaration as required, the application being filed is 
by all or fewer than all the inventors named in the prior application, there is no new matter in the 
application being filed, and a copy of the executed declaration filed in the prior application (showing 
the signature or an indication thereon that it was signed) is submitted. The copy must be accompanied 
by a statement requesting d^etion of the names of person(s) who are not inventors of the application 
being filed. If the declaration in the prior application was filed under § 1.47, then a copy of that 
declaration must be filed accompanied by a copy of the dedsion granting §1.47 status or, if a nonsigning 
person under § 1.47 has subsequently joined in a prior application, then a copy of the subsequently 
executed declaration must be filed. See 37 C.F.R. §§ 1.63(d)(1)-{3). 

NOTE: A declaration filed to complete an application must be executed, identify the specification to which it 
is directed, identify each inventor by full name including family name and at least one given name, without 
abbreviation together with any other given name or initial, and the residence, post office address and 
country or citizenship of each inventor, and state whether the inventor is a sole or joint inventor. 37 
C.F.R. § 1.63(a)(1H4). 

NOTE: "The inventorship of a nonprovi^onaS application is that inventorship set forth in the oath or declaration 
as prescribed by § 1.62, except as provided for in § 1.53(cl){4) and § 1.63(d). If an oath or declaration 
as prescribed by § 1.63 is not filed during the pendency of a nonprovisional application, the inventorship 
is that inventorship set forth in the application papers filed pursuant to § 1.53(b), unless a petition under 
this paragraph accompanied by the fee set forth in § 1.17§ is filed supplying or changing the name 
or names of the inventor or inventors." 37 C.F.R. § 1.41^)(1). 

□ Enclosed 
Executed by 

(check ail applicable boxes) 

□ inventor(s). 

□ legal representative of inventor(s). 
37 C.F.R. §§ 1.42 or 1.43. 

□ joint inventor or person showing a proprietary 
interest on behalf of inventor who refused to sign 
or cannot be reached. 

□ This is the petition required by 37 C.F.R. § 1 .47 and the statement 
required by 37 C.F.R. § 1.47 is also attached. See item 13 below 
for fee. 
0 Not Enclosed. 

NOTE: Where the filing is a completion in the U.S. of an IntemationeJ Application or where the completion of 
the U.S. application contains subject matter in addition to f/ie International Application, the application 
may be treated as a continuation or continuation-in-part, as the case may be, utilizing ADDED PAGE 
FOR NEW APPLICATION TRANSfVinTAL WHERE BENEFfT OF PRIOR U.S. APPLICATION CLAIMED. 

□ Application is made by a person authorized under 37 C.F.R. § 1.41(c) on 
tiehalf of all the above named inventor(s). 
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(The declaration or oath, along with the surcharge required by 37 C.F.R. § 1.16(e) 
can be filed subsequently). 

□ Showing that the filing is authorized. 

(not required unless called into question. 37 C.F.R. § 1.41(d)) 

6. Inventorship Statement 

WARNING: If the named inventors are each not the inventors of all the claims an explanation, including the 
ownership of the various claims at the time the last claimed invention was made, should be 
submitted. 

The inventorship for all the claims in this application are: 

□ The same. 

or 

□ Not the same. An explanation, including the ownership of the various claims at 
the time the last claimed invention was made, 

□ is submitted. 

□ will be submitted. 

7. Language 

NOTE: An application including a signed oath or declaration may be filed in a language other than English. 
An English translation of the non-English language application and the processing fee of $130.00 
required by 37 C.F.R. § 1.17(k)is required to be filed with the application, or within such time as may 
be set by the Office. 37 C.F.R. § 1.52(d). 

1^ English 

□ Non-English 

□ The attached translation includes a statement that the translation is accu- 
rate. 37 C.F.R. § 1.52(d). 

8. Assignment 

^ An assignment of the invention to Nokia Mobile Phones Ltd. 



□ is attached. A separate □ "COVER SHEET FOR ASSIGNMENT (DOCU- 
MENT) ACCOMPANYING NEW PATENT APPLICATION" or □ FORM PTO 
1595 is also attached. 

^ will follow. 

NOTE: "If an assignment is submitted with a new application, send two separate letters-one for the application 

and one for the assignment." Notice of May 4, 1990 (1114 O.G. 77-78). 
WARNING: A newly executed "CERTIFICATE UNDER 37 C.F.R. § 3. 73(b)" must be filed when a continuation- 
in-part application is filed by an assignee. Notice of April 30, 1993, 1150 O.G. 62-64. 
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9. Certified Copy 

Certified copy{ies) of app!ication{s) 



Country 


Appln. No. 


Filed 


Country 


Appln. No. 


Filed 



Country Appln. No. Filed 

from wliich priority is clainned 

□ is (are) attached. 

□ will follow. 

NOTE: The foreign application forming the basis for the claim for priority must be referred to in the oath or 

declaration. 37 C.F.R. § 1.55(a) and 1.63. 
NOTE: This item is for any foreign priority for which the application being filed directly relates. If any parent 

U.S. application or International Application from which this application claims benefit under 35 U.S.C. 

§ 120 is itself entitled to priority from a prior foreign application, then complete item 18 on the ADDED 

PAGES FOR NEW APPUCATION TRANSMHTAL WHERE BENEFIT OF PRIOR U.S. APPUCATION(S) 

CLAff^ED. 

10. Fee Calculation (37 C.F.R. § 1.16) 
A. ^ Regular application 



CLAIMS AS FILED 



Number filed Number Extra Rate Basic Fee 

37 C.F.R. § 1.16(a) 

$6§€r:oo y/cp. cm 

Total 

Claims (37 C.F.R. 

§ 1.16(c)) t/ - 20 = —0 — X $ 18.00 • 

Independent 

Claims (37 C.F.R. ^ 

§ 1.16(b)) ^=^- 3 ^ -O ^ $fft.00 

Multiple dependent claim(s), 

if any (37 C.F.R. § 1.16(d)) + $260.00 



□ Amendment cancelling extra claims is enclosed. 

□ Amendment deleting multiple-dependencies is enclosed. 

□ Fee for extra claims is not being paid at this time. 

NOTE: If the fees for extra claims are not paid on filing they must be paid or the claims cancelled by amendment, 
prior to the expiration of the time period set for response by the Patent and Trademark Office in any 
notice of fee deficiency. 37 C.F.R. § 1.16(d). 

Filing Fee Calculation $ / /O' 0^ 

B. □ Design application 

($310.00—37 C.F.R. § 1.16(f)) 

Filing Fee Calculation $ 
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C. □ Plant application 

($480.00—37 C.F.R. § 1.16(g)) 

Filing fee calculation $. 

11. Small Entity Statement(s) 

□ Statement(s) that this is a filing by a small entity under 37 C.F.R. § 1 .9 and 1 .27 
is (are) attached. 

WARNING: 'Status as a small entity must be specifically established in each application or patent in which 
the status is available and desired. Status as a small entity in one application or patent does not 
affect any other application or patent, including applications or patents which are directly or 
indiKctly dependent upon the application or patent in which the status has been established. The 
refiling of an application under § 1.53 as a continuation, division, or conVnuation-in-part including 
a continued prosecution application under § 1.53(d)), or the fiiing of a reissue application requires 
a new determination as to continued entitlement to small entity status for the continuing or reissue 
application. A nonprovisional application claiming benefit under 35 U.S.C. § 119(e), 120, 121, or 
365(c) of a prior application, or a reissue application may rely on a statement filed in the prior 
application or in the patent if the nonprowsional application or the reissue application includes a 
reference to the statement in the prior application or in the patent or includes a copy of the 
statement in the prior application or in the patent and status as a small entity is still proper and 
desred. The payment of the small entity bas/c statutory filing fee will be treated as such a reference 
for purposes of this section." 37 C.F.R. § 1.28(a)(2). 
WARNING: 'Small entity status must not be estaW/shed when the person or persons signing the. . . statement 
can unequivocally make the required self-certification.' M.P.E.P.. § 509.03, 6th ed.. rev. 2, July 
1996 (emphasis added). 

(complete the following, if applicable) 

□ Status as a small entity was claimed in prior application 

/ , filed on — , from which benefit 

is being claimed for this application under 

35 U.S.C. § □ 119(e), 

□ 120. 

□ 121. 

□ 365(c), 

and which status as a small entity is still proper and desired. 
□ A copy of the statement in the prior application is included. 
Filing Fee Calculation (50% of A, B or C above) 

$ 

NOTE: Any excess of the full fee paid will be refunded if small entitiy status is estaUished and a refund request 
are filed within 2 months of the date of timely payment of a full fee. The two-month period is not 
extendable under § 1.136. 37 C.F.R. § 1.2m- 
12. Request for International-Type Search (37 C.F.R. § 1.104(d)) 
(complete, if applicable) 

□ Please prepare an international-type search report for this application at the time 
when national examination on the merits takes place. 
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13. Fee Payment Being Made at This Time 

^ Not Enclosed 

No filing fee is to be paid at this time. 

(This and the surcharge required by 37 C.F.R. § 1.16(e) can be paid 
subsequently.) 
□ Enclosed 

□ Filing fee $ 

□ Recording assignment 
($40.00; 37 C.F.R. § 1.21(h)) 

(See attached "COVER SHEET FOR 
ASSIGNMENT ACCOMPANYING NEW 

APPLICATION".) $ 

□ Petition fee for filing by other than all the 
inventors or person on behalf of the inventor 
where inventor refused to sign or cannot be 

($130.00; 37 C.F.R. §§ 1.47 and 1.1 7(i)) $ 

□ For processing an application wifri a 
specification in 

a non-English language 

($130.00; 37 C.F.R. §§ 1.52(d) and 1.1 7(k)) $ 

□ Processing and retention fee 

($130.00; 37 C.F.R. §§ 1.53(d) and 1.21(i)) $ 

O Fee for international-type search report 

($40.00; 37 C.F.R. § 1.21(e)) $ 

NOTE: 37 C.F.R. § 1.21(1} estabKshes a fee for processing and retaining any application that is abandoned for 
failing to complete the application pursuant to 37 C.F.R. § 1.53(f) and this, as well as the changes to 
37 C.F.R. §§ 1.53 and 1.78(a)(1). indicate that in order to obtain the benefit of a prior U.S. application, 
either the basic filing fee must be paid, or the proces^ng and retention fee of § 1.210 must be paid, 
within 1 year from notification under § 53(f). 

Total fees enclosed $ — - 

14. Method of Payment of Fees 

□ Check in the amount of $. — 

□ Charge Account No. in the amount of 

$ 

A duplicate of this transmittal is attached. 

NOTE: Fees should be itemized in such a manner that it is clear for which purpose the fees are paid. 37 C. F.R. 
§ 1.22(b). 
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15. Authorization to Charge Additional Fees 

WARNING: If no fees are to be paid on filing, the following items should not be completed. 
WARNING: Accurately count claims, especially multiple dependent claims, to avoid unexpected high charges, 
if extra claim charges are authorized. 
□ The Commissioner is hereby authorized to charge the following additional fees 
by this paper and during the entire pendency of this application to Account No. 

□ 37 C.F.R. § 1.16(a), (f) or (g) (filing fees) 

□ 37 C.F.R. § 1.16(b), (c) and (d) (presentation of extra claims) 

NOTE; Because additional fees for excess or multiple dependent claims not paid on filing or on later presentation 
must only be paid or these claims cancelled by amendment prior to the expiration of the time period 
set for response by the PTO in any notice of fee deficiency (37 C.F.R. § 1.16(d)), it might be best not 
to authorize the PTO to charge additional claim fees, except possibly when dealing with amendments 
after final action. 

□ 37 C.F.R. § 1 .1 6(e) (surcharge for filing the basic filing fee and/or declaration 
on a date later than the filing date of the application) 

□ 37 C.F.R. § 1.17(a)(1)-(5) (extension fees pursuant to § 1.136(a)). 

□ 37 C.F.R. § 1.17 (application processing fees) 

NOTE: ". . A written request may be submitted in an application that is an authorization to treat any concunent 
or future reply, requiring a petition for an extension of time under tiiis paragraph for its timely submission, 
as incorporating a petition for extension of time for the appropriate length of time. An authorization to 
charge all required fees, fees under § 1.17, or all required extension of time fees will be treated as a 
constnjctive petition for an exten^on of time in any concurrent or future reply requiring a petition for 
an extension of time under this paragraph for its timely submission. Submission of the fee set forth in 
§ 1.17(a) will also be treated as a consWctive petition for an extension of time in any concurrent reply 
requiring a petition for an extension of time under this paragraph for its timely submission." 37 C.F.R 
§ 1.136(a)(3). 

□ 37 C.F.R. § 1.18 (issue fee at or before mailing of Notice of Allowance, 
pursuant to 37 C.F.R. § 1.311(b)) 

NOTE: Where an auOiorization to diarge tiie issue fee to a deposit account has been filed before tiie maifing 
of a Notice of Allowance, the issue fee will be automatically charged to the deposit account at the time 
of mailing the notice of allowance. 37 C.F.R. § 1.311(b). 

NOTE: 37 C.F.R. § 1.28p) requires 'Notification of any change in status resulting in loss of entitlement to small 
entity status must be filed in tije application . . . prior to paying, or at the time of paying. . . .the issue 
fee. . . " From the wording of 37 C.F.R. § 1.28(b), (s^ notification of change ofstabjs must be made 
even if tiie fee is paid as 'other than a small entity" and (b) no notification is required if tiie change 
is to another small enti'ty. 
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16. Instructions as to Overpayment 

NOTE: '. . . Amounts of twenty-five dollars or less will not be returned unless speci^cally requested within 
a raasonable time, nor will the payer be notified of such amounts; amounts over twenty-five dollars may 
be returned by check or, if requested, by credit to a deposit account" 37 C.F.R. § 1.26(a). 

□ Credit Account No. — _ 

□ Refund 



Reg. No. 31,391 
Tel. No. (203 261-1234 

Customer No. 00495 5 



SIGNKtURE OF PRACTITIONER 

Francis J. Maquire 




(type or print name of attorney) 

WARE, FRESSOLA, VAN PER SLUYS & ADOLPHSON L 



P.O. Address 

755 Main Street, PO Box 224 

Monroe Ct 06468 Z~7Z. 
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Incorporation by reference of added pages 

(check the following item if the application in this transmittal claims the benefit of 
prior U.S. application(s) (including an international application entering the U.S. 
stage as a continuation, divisional or C-l-P application) and complete and attach 
the ADDED PAGES FOR NEW APPLICATION TRANSMITTAL WHERE BENEFIT OF 
PRIOR U.S. APPUCATION(S) CLAIMED) 

1^ Pius Added Pages for New Application Transmittal Where Benefit of Prior U.S. 
Application(s) Claimed 

Number of pages added ^ 

□ Pius Added Pages for Papers Referred to in Item 4 Above 

Number of pages added _ 

□ Plus added pages deleting names of inventor(s) named in prior application{s) 
who is/are no longer inventor(s) of the subject matter claimed in this application. 

Number of pages added _ _ 

□ Plus "Assignment Cover Letter Accompanying New Application" 

Number of pages added 

□ Statement Where No Further Pages Added 

(if no further pages form a part of this Transmittal, then end this Transmittal with 
this page and check the following item) 
P This transmittal ends with this page. 
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PATENT 



ADDED PAGES FOR APPLICATION TRANSMITTAL WHERE BENEFIT OF 
PRIOR UJS. APPLICATION(S) CLAIMED 

NOTE; See 37 C.F.R. § 1.78. 
17. Relate Back 

WARNING: If an application claims the benefit of the filing date of an eariier filed applicaiion under 35 U.S.C. 

§§ 120, 121 or 365(c), the 20-year term of that application will be based upon the filing date of 
the earliest U.S. application that the application makes reference to under 35 U.S.C. §§ 120, 121 
or 365(c). (35 U.S.C. § 154(a)(2) does not take into account, for the determination of the patent 
term, any application on which priority is claimed under 35 U.S.C. §§ 119, 365(a) or 365(b}.) For 
a c-i-p application, applicant should review whether any claim in the patent that will issue is 
supported by an earlier application and, if not, the applicant should consider canceling the reference 
to the earlier filed application. The term of a patent is not based on a claim-by-claim approach. 
See Notice of April 14, 1995, 60 Fed. Reg. 20,195. at 20.205. 

(complete the following, if applicable) 

Amend the specification by inserting, before the first line, the following sentence: 

A. 35 U.S.C. § 119(e) 

NOTE: "Any nonprovisional application claiming the benefit of one or more prior filed copending provisional 
applications must contain or be amended to corrtain in the first senterKe of the specification following 
the titie a reference to each such prior provisional application, identifying it as a provisional application, 
and including the provisional application number ((X)nsisting of series code and serial numbei).'37 C.F.R. 
§ 1.78(a)(4). 

^ "This application claims the benefit of U.S. Provisional Application(s) No{s).: 

APPUCATION NO(S).: HUNG DATE 

60 / 167 ,924 Nnv. PQ^ 1 PPQ " 
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B. 35 U.S.C. §§ 120, 121 and 365(c) 

NOTE; 'Except for a continued prosecution application filed under § 1.53(d), any nonprovisional application 
claiming the benefit of one or more prior filed copending nonprovisional applications or international 
applications designating the United States of America must contain or be amended to contain in the 
first sentence of the spedfica^on following the title a reference to each such prior application, identifying 
it by application number (consisting of the series code and serial numtxt) or international application 
number and international filing date and indicating the relationship of the applications. . . . Cross- 
references to other related applications may be made when appropriate." (See § 1.14(a)). 37 C.F.R. 
§ 1.78(a)(2). 

□ "This application is a 

□ continuation 

□ continuation-in-part 

□ divisional 

of copending application(s) 

□ application number 0 / filed on " 

□ international Application filed on 

and which designated the U.S." 

NOTE: The proper reference to a prior filed PCT application that entered the U.S. national phase is the U.S. 

serial number and the filing date of the PCT application that designated the U.S. 
NOTE: (1) Where the application being transmitted adds subject matter to the International Application, then 

the filing can be as a continuation-in-part or (2) if it is desired to do so for other reasons then the filing 

can be as a continuation. 

NOTE: The deadline for entering the national phase in the U.S. for an international application was clarified 
in ttie Notice of April 28, 1987 (1079 O.G. 32 to 46) as follows: 

"The Patent and Trademari< Office considers trte Intemationai application to be pending until the 22nd 
montii from the priority date if the United States has been designated and no Demand for Intemationai 
Preliminary Examination has been filed prior to the expiration of the 19th month from the priority date 
and until the 32nd month from the priority date if a Demand for International Preliminary Examination 
which elected the United States of America has been filed prior to tiie expiration of the 19th month 
from the priority date, provided that a copy of ttm intemationai application has txen communicated 
to the Patent and Trademarii Office within the 20 or 30 month period respectively. If a copy of the 
intemationai application has not been communicated to the Patent and Trademark Office within the 
20 or 30 month period respectively, the intemationai application tiecomes abandoned as to the United 
States 20 or 30 montiis from the priority date respectivley. These periods have been placed in the rules 
as paragraph (h) of§ 1.494 and paragraph (i) of§ 1.495. A continuing application under35 U.S.C. 365(c) 
and 120 may be filed anytime during the pendency of the intemationai application." 

□ "The nonprovisional application designated above, namely application 

/ , filed , claims the benefit of 

U.S. Provisional Application{s) No(s).: 



APPLICATION NO{S).: 

/ 

/ 



□ Where more than one reference is made above, please combine all references 
into one sentence. 
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18. Relate Back— 35 U.S.C. § 119 Priority Claim for Prior Application 

The prior U.S. application(s), including any prior International Application designating the 
U.S., identified above in item 17B, in turn itself claim(s) foreign priority(ies) as follows: 

Country Appln. no. Filed on 

The certified copy(ies) has (have) 

□ been filed on , in prior application 0 / , which was 

filed on 

□ is (are) attached. 

WARNING: The certified copy of the priority application that may have been communicated to the PTO by 
the International Bureau may not be relied on without any need to file a certified copy of the priority 
application in the continuing application. This is so becat/se the certified copy of the priority 
application communicated by the International Bureau is placed in a folder and is not assigned 
a U.S. serial number unless the national stage is entered. Such folders are disposed of if the national 
stage is not entered. Therefore, such certified copies may not t>e availatile if needed later in the 
prosecution of a continuing application. An alteniative would be to physically remove the priority 
documents from the folders and transfer them to the continuing application. The resources required 
to request transfer, retrieve the folders, make suitable record notations, transfer the certified copies, 
enter and make a record of such cop/es in the Continuing Application are substantial. Accordingly, 
the priority documents in folders of international applications titat have not entered the national 
stage may not be relied on. Notice ofAfxil 28, 1987 (1079 O.G. 32 to 46). 

19. Maintenance of Copendency of Prior Application 

NOTE: The PTO finds it useful if a copy of the petition filed in the prior application extending the term for 
response is filed with the papers ajnstituting the tiling of the continuation application. Notice of 
November 5. 1985 (1060 O.G. 27). 

A. □ Extension of tinne in prior application 

(TNs item must be compieted and the papers Wed in the prior application, 
if the period set in the prior application has mn.), 

□ A petition, fee and response extends the term in the pending, prior application 
until , 

□ A copy of the petition filed in prior application is attached 

B. □ Conditional Petition for Extension of Time in Prior Application 

(complete this Hem, if previous item not applicable) 

□ A conditional petition for extension of time is being filed In the pending prior 
application. 

□ A copy of the conditional petition filed in the prior application is attached. 
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20. Further Inventorship Statement Where Benefit of Prior Application(s) 
Claimed 

(complete applicable item (a), (b) and/or (c) below) 

(a) □ This application discloses and claims only subject matter disclosed in the prior 
application whose particulars are set out above and the lnventor(s) in this 
application are 

□ the same. 

□ less than those named in the prior application. It is requested that the 
following inventor(s) identified for the prior application be deleted: 



(type name(s) of inventor(s) to be deleted) 
(b) □ This application discloses and claims additional disclosure by amendment and 
a new declaration or oath is being filed. With respect to the prior application, 
the inventor(s) in this application are 

□ the same. 

□ the following additional inventor(s) have been added: 



(type name(s) of inventor(s) to be added) 
(c) The inventorship for all the claims in this application are 

□ the same. 

□ not the same. An explanation, including the ownership of the various claims 
at the time the last claimed invention was made 

□ is submitted. 

□ will be submitted. 
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21 . Abandonment of Prior Application (7f applicable) 

□ Please abandon the prior application at a time while the prior application is 
pending, or when the petition for extension of time or to revive in that application 
is granted, and when this application Is granted a filing date, so as to make this 
application copending with said prior application. 

NOTE: Acxxyding to the Notice of May 13. 1983 (103, TMOG 6-7), the filing of a continuation or continuation-in- 
part application is a proper response with respect to a petition for extension of time or a petition to 
revive and should include the express abandonment of the prior application conditioned upon the 
granting of the petition and the granting of a filing date to the continuing application. 

22. Petition for Suspension of Prosecution for tlie Time Necessary to 
File an Amendment 

WARNING: The daims of a new application may be finally rejected in the first Office action in those situations 
where (/^ tlie new application is a continuing application of, or a substitute for, an earlier application, 
and (B) all the claims of tiw new application (1) are drawn to the same invention claimed in ttie 
earlier application, and (2) would have been properly Anally rejected on the grounds of art of record 
in the next Office action if they had been entered in the earlier application. " M.P.E.P., § 706.07(b), 
7th ed. 

NOTE: Where it is possible that tiie daims on file will give rise to a first action final for this continuation application 
and for some reason an amendment cannot tie filed promptiy (e.g., experimental data is being gathered) 
it may be desirable to file a petition for suspension of pnxecution for the time necessary. 

(check the next item, if applicable) 

□ There is provided herewith a Petition To Suspend Prosecution for the Time 
Necessary to File An Amendment (New Application Filed Concun-ently) 

23. Small Entity (37 C.F.R. § 1.28(a)) 

□ Applicant has established small entity status by the filing of a statement in parent 
application / on . 

□ A copy of the statement previously filed is included. 
WARNING: See 37 C.F.R. § 1.28(a}- 

WARNING: 'Small entity status must not be established when the person or persons signing the . . .statement 
can unequivocally make the required self-certincation." M.P.E.P., § 509.03, 7th ed. (emphasis 
added). 

24. NOTIFICATION IN PARENT APPLICATION OF THIS FILING 

□ A notification of the filing of this 
(check one of the following) 

□ continuation 

□ continuation-in-part 

□ divisional 

is being filed in the parent application, from which this application claims priority under 35 
U.S.C. § 120. 
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TRANSFER OF OPTIMIZATION ALGORITHM PARAMETERS DURING 
HANDOVER OF A MOBILE STATION BETWEEN RADIO 
NETWORK SUBSYSTEMS 

5 

TECHNICAL FIELD 
2nd and 3rd generation cellular packet systems. 

BACKGROUND OF THE INVENTION 

10 In the Global System for Mobile Telecommunications/ 

General Packet Radio Service (GSM/GPRS) network 
architecture, as shown in Fig. 13, there are known data 
protocol stacks associated the various architectural 
elements, including the mobile station (MS) , base station 

15 subsystem (BSS) including Base Transceiver Station (BTS) 
and Base Station Controller (BSC) , serving GPRS support 
node (SGSN) and gateway GPRS support node (GGSN) . The MS 
and the SGSN share peer logical link control (LLC) and 
subnetwork- dependent convergence protocol (SNDCP) layers 

20 in the user plane. 

A typical GPRS negotiation that is required between 
peer entities in the mobile station and some of the fixed 
network devices is the exchange identification or XID 
negotiation, where so-called L3CE (layer 3 compatibility 

25 entity) parameters are agreed upon. 

The UMTS packet network architecture is highly 
similar to GPRS. However, the naming of some elements and 
interfaces has been changed from GPRS. While Fig. 13 
shows the GPRS network architecture. Fig. 14 shows the 

3 0 UMTS packet network architecture. 

The UMTS packet network consists of the following 
network elements : 

Node B: corresponds to Base Transceiver Station (BTS) in 
GSM. 

35 RNC (Radio Network Controller) : corresponds to Base 
Station Controller (BSC) in GSM. 



1 



944-001 . 008-1 



3G-SGSN: the 3""^ Generation version of the Serving GPRS 
Support Node (SGSN) of GSM/GPRS. 

3G-GGSN: the 3"^^ Generation version of the Gateway GPRS 
Support Node (GGSN) . 
5 HLR: the GSM Home Location Register (HLR) with some 
updates . 

As shown in Fig. 14, Node B and RNC comprise the RAN 
part of the UMTS network. RAN corresponds to GSM's BSS . 
The responsibility of RAN is the handling of all radio 

10 specific functions, e.g., radio channel ciphering, power 
control, radio bearer connection setup and release. The 
basic separation between elements is that Node B handles 
the physical layer functions and RNC handles the 
management functions. However, the separation might 

15 ultimately turn out to be slightly different than in 
GSM/GPRS . 

The biggest architectural difference is the new 
interface, lur, inside RAN. It is resident between RNCs . 
UMTS introduces a new concept called macrodiversity . In 

20 a macrodiversity situation, data is sent via multiple 
Node Bs. Because signals are transferred via multiple 
routes over the air interface and combined in the MS and 
the RNC, e.g., the fading effect is less harmful and thus 
lower power levels can be used. However, those Node Bs 

25 may belong to the area of two or more different RNCs, so 
the interface, i.e., lur-interf ace between RNCs is 
required. In this situation, as shown on the right in 
Fig. 15, RNC can be in two logical roles. RNC can be 
logically either: 

3 0 drift RNC (DRNC) or 

serving RNC (SRNC) . 

The actual termination point of the lu- interface is 
at the SRNC. The lu- interface shown in Fig. 14 connects 
the Radio Access Network (RAN) and Core Network (CN) for 
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packet -switched or circuit switched services. The SRNC 
controls information transfer and requests radio 
resources from appropriate DRNCs . The DRNC only relays 
information between MS and SRNC. 

The Core Network (CN) part of the packet -switched 
side consists of 3G-SGSN, 3G-GGSN and HLR elements, as 
shown in Fig. 14. The Packet Core Network (CN) also 
includes the IP-based backbone network. The backbone 
connects core network elements, e.g., 3G-SGSN and 3G-GGSN 
together . 

3G-SGSN participates in routing of user packets as 
well as mobility and session management functions. The 
Mobility Management (MM) layer knows "who you are 
(security) and where you are (mobility) " . The Session 
Management (SM) layer controls the user connections, 
i.e., sessions . 

3G-GGSN maintains the location information of 3G- 
SGSN, which serves the mobile station to which a packet 
is targeted. The main function of 3G-GGSN is to perform 
interworking functions between the UMTS network and the 
external data network, e.g., the Internet. These 
interworking functions include, e.g., the mapping of the 
external QoS to a comparable UMTS QoS . 

HLR stores the subscriber data and holds the 
information to which 3G-SGSN the user is connected. The 
subscriber data includes predefined QoS attributes for 
the user connections, among other things. 

The UMTS packet data protocol stack has some major 
modifications compared to GPRS, partly due to the new 
radio interface technology (WCDMA) and partly due to much 
higher QoS requirements. 

One of the most important changes is that Logical 
Link Control layer (LLC) of ESM/GPRS has been removed 
below the Layer 3 Compatibility Entity (L3CE) . L3CE 
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corresponds to SubNetwork Dependent Convergence Protocol 
(SNDCP) protocol in GPRS. The main tasks of the LLC 
protocol have been: 

flow control between MS and core network, 
5 ciphering, 

signaling message transfer, 
multiplexing of different QoS and 
retransmission between MS and the core network. 
In UMTS, LLC is not needed due to the following 
10 reasons: 1) Ciphering has been decided to take place in 
lower layers, inside RAN. 2) Signaling message transfer 
does not use user plane protocols, because there are 
separate protocols for transferring signaling messages 
and thus the dif f erentation between the user plane and 
15 the control plane is clearer than in GPRS. 

In the UMTS radio interface, each radio bearer will 
have its own Radio Link Control (RLC) entity. By 
applying this approach the QoS provisioning is more 
efficient. The QoS related multiplexing will be a task 
20 for the Medium Access Control (MAC) layer and Layer 1 
(LI) and thus LLC would not have any role in QoS 
multiplexing in UMTS. The retransmission between the MS 
and the core network cannot be easily justified. The main 
source of the errors is the radio interface, and RLC has 
2 5 the responsibility to correct those errors. 

However, the removal of LLC will cause a lack of 
flow control between the MS and the core network. The 
flow control in the uplink is not a problem, because the 
radio interface will be the bottleneck and flow control 
30 of RLC takes care of it. In the downlink, RLC will 
handle the RNC - MS part. Between RNC and the core 
network, there is no flow control. But this is not a 
much worse situation than in GPRS, because GPRS does not 
have any flow control inside the core network (between 
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GGSN and SGSN) . 

Adequate data transfer between 3G-GGSN and RNC 
relies on large enough buffers, traffic policing in 3G- 
GGSN and end-to-end flow control, e.g.. Transmission 
Control Protocol (TCP) . In general, the removing of LLC 
streamlines the protocol stack and makes it easier to 
achieve higher data rates and reduces required processing 
power . 

The location of the UMTS counterpart to L3CE (SNDCP 
in GPRS) called Packet Data Convergence Protocol (PDCP) 
is under consideration. Unlike in GPRS the PDCP layer is 
located in RNC instead of SGSN. The protocol inter alia. 
takes care of optimization, e.g., by header compression, 
which is a form of optimization algorithm. Some header 
compression algorithms are based on the principle that 
disappearence of a few packets may cause undesirable 
additional packet loss due to the algorithm itself . This 
degrades packet transfer because more retransmissions are 
needed to be done. By locating it to the RNC, the 
retransmission time is short and the TCP level 
retransmission (due to TCP timers) can be avoided. 

Network layer protocols are intended to be capable 
of operating over services derived from a wide variety of 
subnetworks and data links. The PDCP supports several 
network layer protocols providing protocol transparency 
for the users of the service. An introduction of new 
network layer protocols to be transferred over PDCP 
should be possible without any changes to other UMTS 
protocols. Therefore, all functions related to 
transferring of Network Layer Protocol Data Units (N- 
PDUs) are carried out in a transparent way by the network 
entities. Another requirement for PDCP is to provide 
functions that improve data and channel efficiency. This 
is done by different kind of optimization algorithms or 
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methods, e.g., the above-mentioned header compression. 

UMTS (Universal Mobile Telecommunications System) , 
as shown in Fig. 14, utilizes similar protocol structures 
and negotiation arrangements for communication between 
5 mobile stations. Radio Network Controllers (RNCs) and 
service nodes of packet -switched networks, with some 
modification. Exchange Identification (XID) negotiation 
is carried out by the PDCP but is called PDCP parameter 
negotiation and can be viewed generally as a transfer of 
10 optimization algorithm parameters. 

In either case, the negotiated parameters will 
relate to such optimization algorithm parameters, for 
example, to the use of headers and data compression. The 
GSM/GPRS method for arranging an XID negotiation is to 
15 insert the proposed parameters into certain messages in 
an LLC protocol layer and to use corresponding LLC -level 
answering messages to either acknowledge or reject the 
proposed SNDCP parameters. 

The XID negotiation is usually made when SNDCP and 
20 LLC in GPRS are initialized (values for XID parameters 

are no longer valid). This initialization is made, e.g., 
when the MS is powered on or the location of network side 
protocols changes in handover. 

The main problem of the currently-proposed XID 
25 negotiation method for UMTS is that the location of PDCP 
is different from the location of SNDCP and LLC protocol. 
PDCP locates in the radio access network while comparable 
GPRS protocols locate in core networks. This means that 
the location of PDCP changes far more often than the 
3 0 locations of SNDCP and LLC. Because XID messages may be 
relatively large, this adds much more overhead to the air 
interface in UMTS than in GPRS. 

Another problem is that UMTS has also real time 
packet connections. This means that negotiations such as 
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XID should be as fast as possible, because otherwise it 
may cause delays or at least more overhead in the air 
interface (header compression cannot be used after 
handover until XID negotiation is successfully made) . 

SUMMARY OF INVENTION 
The object of the invention is to provide for 
improved UMTS as well as GSM/GPRS negotiation methods. 

This invention improves any negotiation, such as 
optimization algorithm parameter negotiation, e.g., XID 
negotiation, by reducing the overhead over the air 
interface and making the negotiation procedure faster. 
The basic idea of the invention is that during handover, 
parameters such as XID, containing parameter information 
about optimization methods to be supported, are 
transferred from the old entity to the new entity on the 
network side. If the parameters were appropriate in the 
new entity, the actual negotiation between the MS and the 
network is not needed, thus saving resources on the air 
interface. This method is also considerably faster than, 
for instance, normal XID negotiation. 

According to the present invention, a method of 
negotiating such as negotiating optimization algorithm 
parameters, for instance exchange identification (XID) 
parameters during connection handover of a mobile station 
between radio network subsystems, comprises the steps of 
signaling from a source radio network subsystem to a core 
network or to a target radio network subsystem that said 
handover is required, signaling from the core network or 
from the target radio network subsystem to the source 
radio network subsystem that said handover is to proceed, 
and transmitting said parameters from said source radio 
network subsystem to said target radio network subsystem 
directly or via the core network without any need for 
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renegotiating over an air interface between said mobile 
station and said target radio network subsystem. 

In further accord with the present invention, 
wherein during initial establishment of said connection 
between the mobile station and the source radio network 
subsystem, the optimization algorithm paramaters such as 
exchange identification parameters may include various 
optional sets of parameters, only one of which is 
accepted by the source radio network subsystem, said 
method further comprising the step of storing all of said 
optional sets of parameters wherein said step of 
transmitting said parameter includes transmitting all of 
said optional sets of parameters . 

From the foregoing, it will be realized that the 
present invention indeed saves resources for the air 
interface and makes any kind of negotiation, including 
negotiation of parameters relating to optimization 
methods such as XID faster, which is advantageous for 
real time connections. 

These and other objects, features and advantages of 
the present invention will become more apparent in light 
of the detailed description of a best mode embodiment 
thereof, as illustrated in the accompanying drawing. 

BRIEF DESCRIPTION OF THE DRAWING 

Fig. 1 shows a source radio network controller (RNC) 
moving already-negotiated XID parameters to a target RNC 
during handover, according to the present invention. 

Fig. 2 shows a simplified procedure of SRNS 
relocation according to the present invention. 

Fig. 3 shows an MSG connecting to the network. 

Fig. 4 shows MSG initialization. 

Fig. 5 shows MSG SRNS relocation. 

Fig. 6 also shows MSG SRNS relocation. 
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Fig. 7 shows a situation before SRNS relocation and 
location registration. 

Fig. 8 shows the situation after the SRNS relocation 
and location registration. 

Fig. 9 shows how Figs. 9A and 9B fit together. 

Figs. 9A and 9B together show the signaling sequence 
concerning interface information transfer for SRNS 
relocation update when changing SGSN area resulting in a 
change of register location and followed by location 
registration in a new location area. 

Fig. 10 shows data paths before the SRNS relocation 
has been actually committed. 

Fig. 11 shows data paths after the GGSN update. 

Fig. 12 shows data paths after the resource release 
in the source RNC . 

Fig. 13 shows the GPRS network architecture. 

Fig. 14 shows the UMTS packet network architecture. 

Fig. 15 shows two logical RNCs . 

BEST MODE FOR CARRYING OUT THE INVENTION 
The first XID negotiation after the MS is connected 
to the network is always a normal GPRS type of XID 
negotiation, as in the prior art. The GPRS XID parameter 
negotiation as part of the SNDCP protocol is defined in 
TS 101 297 v.6.4.0 (1999-08) (GSM 04.65 version 6.4,0 
Release 1997 (chapter 6.8)). 

Similarly, during inter RNC handover (SRNS 
relocation) , according to the currently-proposed 
evolution of the GSM platform towards UMTS, the control 
point of data transfer moves from a source RNC (RNC 1) to 
a target RNC (RNC 2) and thus a new PDCP entity is 
established to the target RNC network element. However 
this new PDCP entity should negotiate XID parameters, 
before it starts data transfer towards the MS (PDCP can 
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transfer data before it knows negotiated XID parameters, 
but then it is allowed only use default values of XID 
parameters -> no optimization is allowed, e.g., header 
compression) . 

The prior art basic solution (as in GPRS) is still 
that the target RNC makes normal XID negotiation between 
itself and the MS and after that starts data transfer. 

A more advantageous solution according to the 
present invention, and as illustrated in Fig. 1, is that 
the source RNC IS (RNC 1) moves the already-negotiated 
XID parameters to the target RNC 2 0 (RNC 2) during 
handover, i.e., SRNS relocation directly or via SGSN 26 
(see 3G TS 23.121 v3 . 0 . 0 - chapter 4.3.12.2.3). 

Fig. 1 shows a pair of radio network subsystems 11, 
12 connected to the core network 14 through an lu 
interface. The radio network system 11 consists of a 
radio network controller 16 and one or more abstract 
entities 18, which may be called Node B, which 
corresponds to the Base Transceiver Subsystem of GSM. 
The entities of Node B are connected to the RNC through 
an lub interface. A Node B can support FDD mode, TDD 
mode or dual -mode operation. The RNC is responsible for 
handover decisions that require signaling to the mobile 
station 10 over a Uu interface. The RNC comprises a 
combining/splitting function to support macrodiversity 
between different Node Bs. The Node B can comprise an 
optional combining/splitting function to support 
macrodiversity inside a Node B. The RNCs 16, 20 of the 
radio network subsystems 11, 12 can be interconnected 
together through an lur interface, as already discussed 
previously in connection with Fig. 14. 

Each RNC is responsible for the resources of its set 
of cells. For each connection between a user equipment, 
such as the mobile station MS 10 of Fig. 1, and the 



944-001 . 008-1 



illustrated access/core architecture, one RNC is the 
serving RNC. In Fig. 1, the RNCl 16 is initially the 
serving RNC. The RNC2 20 serves as a drift RNC (see also 
Fig, 15) and supports the serving RNCl 16 by providing 
5 radio resources for possible handover. Upon such a 
handover, as suggested above, during the inter-RNC 
handover, the control point of data transfer moves from 
RNCl 16 to RNC2 20 for establishing a new PDCP entity to 
the target RNC2 20. According to the prior art, this new 
10 PDCP entity should first negotiate PDCP parameters, 
before it starts data transfer to the MS, unless it 
wishes to only use the default values, i.e., without 
optimization . 

According to the present invention, rather than 
15 renegotiating, such as renegotiating optimization 

algorithm parameters, for instance PDCP parameters all 
over again, the RNCl 16 transfers the already-negotiated 
PDCP parameters to RNC2 20, as indicated on a line 24, 
which transfer may take place over the lur interface or 
2 0 through the core network 14, e.g., via a serving GPRS 
support node (SGSN) 26. 

Fig. 2 shows an embodiment that represents a 
simplified procedure of SRNC relocation where two SGSNs 
are involved in the core network. One possible solution 
25 for PDCP parameter transfer is the use of SRNC relocation 
messages (e.g., SRNC_Relocation_Required 30, 
Forward_SRNC_Relocation 32 (e.g., if RNSl and RNS2 are 
connected to different SGSNs, to possibly another SGSN 27 
not shown in Fig. 1) , SRNC_Relocation_Request 34 to the 
30 target SRNC 20, SRNC ' s Relocation_Proceeding 1 36, 
Forward_SRNC_Relocation Response 38, 

SRNC_Relocation_Proceed 2 40, SRNC_Relocation_Commit 42, 
RNC_Restart_44, Data_Transmission_Begin 46, 
PDCP_Parameter_Request (if needed) 48, 



11 



944-001 . 008-1 



PDCP_Parameter_Response (if needed) 50) . The format of 
PDCP parameters can be the same as in normal prior art 
XID negotiation. After the target RNC2 20 receives these 
PDCP parameters, it checks their validity. If they are 
valid, it can use the parameters immediately. Otherwise 
the target RNC makes a normal XID-type negotiation, as 
suggested in Fig. 2 at steps 48, 50. So PDCP negotiation 
between the MS and the target RNC is made only when PDCP 
parameters are not valid in the target RNC and therefore 
air resources are saved. 

However, the MS requires information about the 
validity of the PDCP parameters before it can send data 
to the RNC (MS can't otherwise know whether PDCP 
parameters were alright in the RNC) . There are two 
options : 

Preferable solution: RNC informs the MS about 
validity of XID parameter during/before RLC restart 
within separate message, e.g., during step 44 of Fig. 2. 

If PDCP parameters were valid, both ends can use same 
negotiated PDCP parameters immediately. If PDCP 
parameters were not valid, PDCP negotiation is made after 
restart, as shown, e.g., in steps 48, 50. Until PDCP 
negotiation is completed, all data packets are sent in 
uncompressed mode, i.e., the default mode. 

Another solution: It can be guaranteed, that PDCP 
parameter negotiation can be made before data transfer 
(preferably before RLC restart step 44) , if it is needed. 
(This might cause delays to SRNC relocation, however.) 

This retrieval of PDCP parameters from the source 
RNC, as described so far, has one disadvantage. The 
target RNC can't know if the MS can handle 'better' PDCP 
parameters, e.g., better compression methods than 
originally negotiated between the MS and the source RNC 
16 (RNC 1) . 
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Example : 

MS can handle header compression methods A and B 

RNC 1 can handle header compression method A 

RNC 2 can handle header compression methods A and B. 

Because PDCP negotiation is made originally by RNC 
1, only header compression A is negotiated for use. 
After SRNC relocation, RNC 2 checks the validity of the 
PDCP parameters. In the example they are valid, because 
RNC 2 can handle header compression A. The problem is 
that, in this situation, PDCP negotiation between MS is 
not made and header compression B is not taken up for 
use. If the header compression B is significantly 
better, it causes inefficiency. (Normal PDCP negotiation 
takes always the best XID parameters for use.) 

This problem can be avoided, according further to 
the invention, with the following enhancements: 

Firstly, the initial XID negotiation (first XID 
negotiation after MS is connected to the network) is 
always started from the MS side. (This is a normal 
situation in GPRS) . The MS defines and puts suitable 
PDCP parameters into the PDCP message. Then the peer 
entity, i.e., RNC, negotiates, i.e., selects appropriate 
PDCP parameters and sets suitable values to them. After 
that the RNC returns negotiated XID parameters to the MS 
and the negotiated parameters are taken up for use , 

However, if the RNC stores in addition to negotiated 
PDCP parameters also the 'not used' or discarded PDCP 
parameters (in the example, it stores information on 
header compression B) , when SRNC relocation is made, the 
'not used' PDCP parameters are retrieved from storage and 
are also transferred to the target RNC. (The same SRNC 
relocation messages are used then on transfer or 
negotiated PDCP parameters.) According to this 
information, the target RNC can decide if those 'not 
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used' XID parameters are 'better' (in the example, header 
compression B) than currently negotiated and make PDCP 
negotiation between MS to take up for use new and 

'better' XID parameters. 

A few examples of Negotiation of Header Compression 

(HC) parameters according to the invention will now be 
given . 

Example 1 : 

An example of negotiation of header compression (HC) 
parameters is shown in Fig. 3. When Mobile Station 
connects to the network RRCs with a UE CAPABILITY 
INFORMATION message is used to inform the SRNC of the 
header compression (HC) methods that UE is able to use 
and the parameters thereof. This information is left to 
the network to be updated and taken care of . 

After comparing the network's own and these received 
parameters, the network makes a decision of the HC-method 
to be used, also taking into consideration the QoS 
requirements. Thus it is possible to choose the most 
probable HC method (in other words, according to QoS 
requirements the first configured method can be chosen to 
be real-time traffic optimized method or not) . After the 
network has made the decision it configures its own 
compressor, generates the OPT value table and commands 
using RRC messages RADIO BEARER SETUP (Fig. 4) or RADIO 
BEARER RECONFIGURATION (Fig. 5) the parameters relating 
to that algorithm with which the compressor in the UE end 
is configured. At the same time the OPT table is 
generated to match the table of the network's end. The 
VE_RRC responds with a RADIO_BEARER_SETUP_COMPLETE (Fig. 
4) message to the SRNC_RRC or with a 

RADIO_BEARER_RECONFIGURATION_COMPLETE (Fig. 5) message in 
case of reconfiguration. 
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Because the network knows (Fig. 3) which algorithms 
the UE and the network itself are able to use, it is 
possible to configure a new compressor in case other 
kinds of packets (different from what is supported by 
5 current compressor) are recognized and the compression of 
these is supported by the network and the UE. In that 
case, new compressors will be configured at both ends 
immediately. If the notification is in the UE end, these 
are sent firstly to the RNC uncompressed and after the 

10 RNC notices the situation it configures the compressors 
at both ends. The new compressor at the UE end is 
configured using a RADIO BEARER RECONFIGURATION (Fig. 5) 
message containing the information, which is sent when 
the new method is being configured. 

15 Because the network maintains the information of all 

possible methods for use at both the UE and the network 
and because only the most probable method is being 
configured, it is possible to leave the compressors of 
other methods to be configured later if needed. 

20 In case of SRNS relocation, as detailed in Fig. 6, 

after the last SRNC_reloca.t±on_Commit message, a new RNC 
RADIO BEARER RECONFIGURATION (Fig. 5) message is sent, 
wherein new HC parameters are communicated if the method 
changes. In case the method doesn't change, only old 

25 parameters are communicated and information about the 
reset (yes/no) of the compressor is transmitted. If 
there is no resetting then the compression/decompression 
continues as it was in the old RNC. 

3 0 Example 2 : 

Again, when the Mobile Station connects to the 
network RRCs with the UE CAPABILITY INFORMATION message 
of Fig. 3, the SRNC_RNC is informed of the desired header 
compression (HC) methods that the UE is able to use and 
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the related parameters. This information is left to the 
network to be updated and taken care of . 

The network chooses the methods that can be 
supported based on its own supported methods as well as 
5 those of the UE. After this the network could send the 
parameters of all the supported methods at the same time 
with a message to the UE . This would mean that both the 
network and the UE would know which methods can be 
supported. In this case also the OPT table indicating 

10 different packet types of different methods is generated 
to be similar at both ends. This information transfer 
can be carried out by using RRC's RADIO BEARER SETUP, as 
shown in Fig. 4, or RADIO BEARER RECONFIGURATION 
messages, as shown in Fig. 5. At the same time the most 

15 probable method is informed and configured and the 
compressor is created. 

In case the configured compressor is, e.g., TCP/IP 
but afterwards RTP/UDP/IP real-time packets are 
recognized, PDCP recognizes the situation and generates a 

20 new compressor for those. This new RTP/UDP/IP compressor 
is configured and inside the compressor the stream-based 
contexts are generated and stream-based Full Headers (FH) 
are sent to the other end. The link layer informs using 
the OPT-field about what compression method is in 

25 question and that it deals with that method's Full Header 
(FH) . The other end notices the situation, configures the 
decompressor and generates (using FHs) the correct 
internal contexts for existing streams. In this 
situation no RADIO BEARER RECONFIGURATION messages need 

3 0 to be sent. After this the compressor is able to send 
compressed packets without further acts. This solution 
works independently of the transmission end (UE/network) . 

Another solution is that for all supported methods 
each end's own compressors are configured immediately in 
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the beginning, meaning that compressor configuration is 
done only once. In this case inside the compressor only 
the own specific stream-based contexts are generated and 
stream-based Full Headers (FH) are sent to the other end. 
5 Also if the same compressor supports two methods the 
configuration is not needed but only one ' s own stream- 
based compressor contexts are generated and FHs sent to 
the other end. 

Again, in SRNS relocation after 

10 SRNC_reloca.tion_Cormit message, as shown in Fig. 6, a new 
RNC RADIO BEARER RECONFIGURATION message is being sent 
{Fig. 5) , wherein the UE is informed if the method 
changes. In case the method doesn't change only 
information about the reset (yes/no) of the compressor is 

15 sent. If there is no resetting then the 

compression/decompression continues as it was in the old 
RNC. 

Example 3 : 

20 It is also possible that network informs the UE 

about the methods it supports when connecting to the 
network and in case of SRNS relocation after 
SRNC_relocation_Commit message. In this case UE begins 
the transmission of compressor parameters using some 

2 5 RADIO BEARER SETUP (Fig. 4) and RADIO BEARER 

RECONFIGURATION (Fig. 5) based signaling and the 
compressor generating procedure according to example 1 or 
2 with the difference that UE sends the configuration 
messages and network receives them. 

3 0 The current (prior art) solution in GPRS is that XID 

negotiation is made again when the location of SGSN 
changes (inter SGSN handover) . This negotiation is 
required, because the SNDCP and LLC protocols locate in 
SGSN and the old XID parameters are not known in the new 
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SGSN (and they may also be non-applicable) . XID 
negotiation is made for certain (most, but not all) LLC 
and SNDCP parameters, e.g., header compression 
parameters . 

5 However, this approach is not very suitable for 

UMTS. 

In UMTS, the PDCP is located in RNC, so negotiation 
will have to be made more often. 

UMTS has real time bearers also for packet data. 
10 - Negotiation would be fast as possible. 

Note: PDCP parameter negotiation is probably not to 
be named XID-negotiation, just PDCP parameter negotiation 
in UMTS. 

15 Possible alternatives to make PDCP negotiation between UE 
and target RNC : 

In the following, SRNS relocation is described in 
detail. All necessary information is transferred from 
the source RNC to the target RNC. 

2 0 - negotiated PDCP parameters -> target RNC, whether they 

are OK or not for it. If they are, new negotiation is 
not needed and air resources and time are saved. 
- UE capability information -> this includes UE ' s PDCP 
capability information among other capabilities. PDCP 
25 capability information may contain, e.g., the following 
information: PDCP version number and supported header 
compression methods and other parameters. This is not 
mandatory. 

3 0 1) One solution is that network commands (RRC 

protocol in RNC) , what parameters are used in the UE (in 
different radio layer protocols, LI, MAC; RLC, PDCP) . 
This is not an actual two-way negotiation like XID 
negotiation. However the network shall know what 
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parameters the UE is able to support (because the network 
can't command what the UE can't support) . This UE 
capability can be transferred from source SRNC 

(suggested) or requested from the UE by ' UE capability 
enquiry' (see RRC specification - TS 2 5.331 vl . 5 . 0 : 
Chapters 8.1.6 and 8.1.7). Now the target SRNC can 
negotiate (command) new parameters for the UE. The 
current (prior art) solution is that the parameters are 
transferred within 'Radio Bearer Setup/Reconfiguration' 
messages (see TS 25.332: Chapter 8.2). Actual PDCP 
parameters should probably be named as 'PDCP Info' like 

'RLC info' (see table in chapter 10.1.5.4). Also other 
messages (new or existing ones) are possible. 

In a case where the parameters were OK in the target 

SRNC: 

- An indication is provided that previously negotiated 
parameters were OK. Both sides use old parameters. This 
indication can be one's own RRC level message or part of 
a 'Radio Bearer Setup/Reconf iguration ' -message . This 
indication can be very short (1 bit) , to indicate whether 
the negotiated parameters were OK or not. 

In a case when parameters were not OK in the target 

SRNC: 

- The target RNC commands new parameters taking into 
consideration the UE ' s capability. (Normal PDCP 
parameter negotiation) . 

In this solution, there is no time saving, because 
negotiation is one way. 

2) In this solution, PDCP parameter negotiation is 
two-way between the network (RNC) and the UE. In this 
case, UE capability information is not mandatory (but 
such may help the target SRNC, when it negotiates new 
parameters) . After SRNC receives the to be negotiated 
parameters, it checks the suitability of the parameters. 
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In a case where parameters are OK in target SRNC: 

- An indication is provided that the previously 
negotiated parameters are OK. Both sides use the old 

5 parameters. This indication can be one's own RRC level 
message or part of a 'Radio Bearer 

Setup/Reconf igurat ion' -message . This indication can be 
very short (1 bit) , to indicate whether negotiated 
parameters were OK or not . 
10 In a case where parameters were not OK in target 

SRNC: 

- The target RNC negotiates new parameters. (Two-way 
PDCP parameter negotiation) . First direction message 
(request) may be same as in solution 1), i.e., 'Radio 

15 Bearer Setup/Reconf iguration ' , such as in Figs. 4 or 5 , 
and second direction message (reply) could be 'Radio 
Bearer Setup/Reconfiguration Complete' (see chapter 
10.1.5.5). Also new (own) messages for PDCP negotiation 
in RRC protocol may be possible. 

20 In this solution, time is saved, because two-way 

negotiation needs to be made only when parameters weren't 
OK. 

Note: In both solutions it is assumed that the RRC 
makes the PDCP negotiation and after negotiation (if 

25 needed) RRC informs new parameters to PDCP. An 

alternative solution is that PDCP makes the negotiation 
by itself. Then RRC messages are not used, but PDCP uses 
its own PDUs for negotiation. However the basic 
principles are the same also in this case. 

3 0 A similar approach could be used also in future 

releases of GPRS. 

SRNS relocation principles according to 3G TS 23.121 v 
3.1.0 (1999-10) 3G PP Technical Specification Group 



20 



944-001 . 008-1 



Services and Systems Aspects; Architectural Requirements 
for Release 1999 at Section 4.3.14.2, as modified 
according to the present invention: 

5 According to Chapter 4.3.14.2.1 of 3G TS 23.121, to 

carry out SRNS relocation, the source SRNC must launch 
the SRNS relocation procedure, since it is not the target 
SRNC but the source SRNC that knows the current services 
of a user. This is done only when this procedure has the 

10 least adverse effect on user traffic. The SRNC 

relocation procedures must ensure that there is only one 
Serving RNC for a user even if this user has services 
through more than one (IP or ISDN) domain. 

The SRNS relocation procedure is split in two 

15 phases. In the first phase resources are reserved on the 
new lU interfaces and (if needed) inside the CN, Only 
when this first phase has been successfully carried out 
for all domains on which the user currently has some 
services, can the source SRNC launch the second phase, 

20 i.e., handover of the role of SRNC to the target SRNC. 
The signaling procedures shown below do not 
represent the complete set of possibilities, according to 
the TS 23.121 specification, nor do they mandate this 
kind of operation. It should be understood according to 

25 the standard, that a set of elementary procedures should 
be specified for each interface, which may be combined in 
different ways in an implementation. Therefore the 
illustrative sequences are merely examples of a typical 
implementation. In these examples from the 3G TS 23.121 

3 0 standard, MSC stands for 3G_MSC/VLR and SGSN stands for 
3G SGSN. 
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SRNS relocation 
{UE connected to a single CN node, 3G_SGSN) 
followed by Location Registration in new Location Area as 
per Chapter 4.3.14.2.3 of 3G TS 23.121 as modified by the 
present invention 

This example shows SRNS relocation when source RNC 
and target RNC are connected to different 3G_SGSNs . Fig. 
7 and Fig. 8 respectively illustrate the situation before 
and after the SRNS relocation and location registration. 
Fig. 9 illustrates the signaling sequence where each step 
is explained below. 

As shown in Fig. 7, before the SRNS relocation and 
location registration the UE is registered in SGSNl and 
in MSCl . The UE is in state MM connected towards the 
SGSNl and in state MM idle (see Chapter 4.3 UMTS Mobility 
Management (UMM) in 3G TS 23.121) towards the MSCl. The 
RNCl is acting as SRNC and the RNC2 is acting as DRNC. 

After the SRNS relocation and location registration 
as shown in Fig. 8, the UE is registered in MSC2 and in 
SGSN2 . The UE is in state MM connected towards the SGSN2 
and in state MM idle towards the MSC2 . The RNC2 is 
acting as SRNC. 
At SRNS relocation: 

The source and target SGSN exchange CN level information 
(CN classmark, list of established PDF contexts) 

The source and target SRNC exchange UTRAN level 
information (UTRAN classmark, ...) and information used 
to ensure that no user packet is lost nor duplicated 
during the SRNS relocation procedure . According to the 
teachings of the present invention, this UTRAN level 
information also includes negotiated PDCP (XID) 
parameters . 
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"Resource reservation" Phase 
During this phase, according further to Chapter 
4.3.14.2.3 of 3G TS 23.121 v 3.1.0 (1999-10), the 
5 transmission of packets between GGSN and UE through the 
source SRNC goes on. The following numbered paragraphs 
correspond to the numbered steps in Figs. 9A and 9B, 
which fit together as shown in Fig. 9. 

1. UTRAN (source SRNC) makes the decision to perform 
10 the Serving RNC relocation procedure. This includes a 

decision on into which RNC (Target RNC) the Serving RNC 
functionality is to be relocated. The source SRNC sends 
SRNC Relocation Required messages to the SGSNl . This 
message includes parameters such as target RNC identifier 

15 and an information field that shall be passed 

transparently to the target RNC. According to the present 
invention, this may include negotiated PDCP (XID) 
parameters, UE capability (e.g., supported header 
compression methods by UE) and any other related 

20 parameters. 

2. Upon reception of SRNC Relocation required message 
the SGSNl determines from the received information that 
the SRNC relocation will (for instance, in this case) 
result in a change of SGSN. 

25 The SGSN will then send a Forward SRNC relocation 

request to the applicable SGSN (e.g., SGSN2) including 
the information received from the Source SRNC (see above 
PDCP (XID) parameter information according to the 
invention) and necessary information for the change of 

30 SGSN (e.g., MM context, PDP context). The PDP context 
information contains the list of the PDP context 
(including PDP type, requested/negotiated QoS) currently 
established by the UE along with the address of the 
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associated GGSN. It does not contain any information 
linked with packet transmission (sequence numbers) 
because such information is under the responsibility of 
the UTRAN. 

3 . The SGSN2 sends a SRNC Relocation Request message to 
the target RNC . This message includes information for 
building up the SRNC context, transparently sent from 
Source SRNC (e.g., UE id., number of connected CN nodes, 
UE capability information (including the inventive 
information transfer relating to PDCP (XID) parameters 
described above) , and directives for setting up lu user 
plane transport bearers . 

When the lu user plane transport bearers have been 
established, and the target RNC completed its preparation 
phase, SRNC Relocation Proceeding 1 message is sent to 
the SGSN2, as shown in Figs. 9A and 9B . The SRNC 
Relocation Proceeding 1 message contains the IP 
address (es) (possibly one address per PDP context) on 
which the target RNC is willing to receive these packets . 

4 . When the traffic resources between target RNC and 
SGSN2 has been allocated and the SGSN2 is ready for the 
SRNC move, then the Forward SRNC Relocation Response is 
sent from SGSN2 to SGSNl . This message indicates that 
necessary resources have been allocated for the SRNC 
relocation: SGSN2 /target RNC are ready to receive from 
source SRNC the downstream packets not yet acknowledged 
by UE. The Forward SRNC Relocation Response message 
contains the IP address (es) that were given in the SRNC 
Relocation Proceeding 1 message. 

5 . When the Forward SRNC Relocation Response has been 
received in the SGSNl, the SGSNl indicates the completion 
of preparation phase at the CN PS domain side for the 
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SRNC relocation by sending the SRNC Relocation Proceeding 
2 message to the Source RNC . This message contains the 
IP address (es) (possibly one address per PDP context) on 
which to send the downstream packets not yet acknowledged 
5 by UE. 



"Actual hand-over of Serving RNC" Phase 

6 . When the source RNC has received the SRNC Relocation 
Proceeding 2 message, the source RNC sends a SRNC 

10 Relocation Commit message to the target RNC (list of 

(SNU, UP_RLC_Ack, SND) ) . SND is the GTP sequence number 
for the next downlink packet received from the GGSN. SNU 
is the GTP sequence number for the next uplink packet to 
be tunnelled to the GGSN. UP_RLC_Ack contains the 

15 acknowledgements for an upstream PDU received by the 

source SRNC on each RLC connection used by the UE (i.e., 
the Receive State Variable V(R) for all RLC SAPI in the 
acknowledged mode) . The source SRNC starts a timer T3- 
TUNNEL, stops the exchange of the packets with the UE 

20 (point (a) ) , and starts tunnelling the buffered 

downstream packets towards the target SRNC. The target 
RNC executes a switch for all bearers at the earliest 
suitable time instance. In this phase, according to the 
present invention, new PDCP parameters are to be 

25 negotiated if needed. See the description above 

concerning possible alternatives for PDCP negotiation 
between the UE and the RNC. 

7. The target RNC starts acting as SRNC and the 
remaining steps 7-14 of Chapter 4.3.14.2.3 of 3G TS 

30 23.121 V 3.1.0 (1999-10) remain the same and are 

unaffected by the present invention. The target SRNC: 
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(a) Restarts the RLC connections. This includes the 
exchange between the target SRNC and the UE of the 
UP_RLC_Ack and DOWN_RLC_ACK . DOWN_RLC_ACK confirms 
all mobile-terminated packets successfully 

5 transferred before the start of the relocation 

procedure. If DOWN_RLC_ACK confirms reception of 
packets that were forwarded from the source SRNC, 
then these packets shall be discarded by the target 
SRNC. UP_RLC_Ack confirms all mobile -originated 
10 packets successfully transferred before the start of 

the relocation procedure. From now on the exchange 
of the packets with the UE can restart (point (b) ) . 

(b) Sends New MM System Information to the UE 
indicating, e.g., relevant Routing Area and Location 

15 Area. A new RAI triggers a routing area update 

procedure. Additional RRC information may then also 
be sent to the UE, e.g., new RNTI identity. This 
may trigger a location update procedure (see step 12 
below) . 

20 8. Immediately after a successful switch at RNC, target 
RNC (=SRNC) sends SRNC Relocation Detect message to the 
SGSN2 . After sending out the New MM System Information, 
the target RNC sends SRNC Relocation Complete message to 
the SGSN2. 

25 9. The UE sends a Routing area update request (old RAI; 
old P-TMSI; old PTMSI signature. Update type) to SGSN2 
when the New MM System Information included a new RAI. 

10. Upon reception of RAU request, the SGSN2 updates the 
GGSN(s) with an Update PDP Context Request including the 
3 0 new SGSN address. The GGSN(s) then update the PDP 

context and return Update PDP Context Response. The SGSN 



26 



944-001. 008-1 



sends a Complete SRNC Relocation towards the SGSNl . 

11. At reception of the Complete SRNC Relocation, SGSNl 
will send a release indication towards the Source RNC. 
All resources allocated to this UE by the source RNC are 
released only when this message has been received and 
timer T3 -TUNNEL has expired. Before timer T3 -TUNNEL 
expires, all downstream packets received from the GGSN 
are sent towards the target SRNC. 

12 . The SGSN2 informs the HLR of the change of SGSN by 
sending Update GPRS location (IMS I, new SGSN address 
etc.) to the HLR. The HLR cancels the context in the old 
SGSN, SGSNl, by sending Cancel Location (IMSI) . The 
SGSNl removes the context and acknowledges with Cancel 
Location Ack . The HLR sends Insert subscriber data 
(IMSI, subscription data) to the SGSN2 . The SGSN2 
acknowledges with Insert Subscriber Data Ack. The HLR 
acknowledges the Update GPRS location by sending Update 
GPRS Location Ack to the SGSN2 . 

13. At reception of Insert subscriber data from HLR, the 
SGSN2 will initiate the update of MM information stored 
in the UE . This is done by sending Network Initiated 
Routing Area Update Command to the UE . This message will 
include new RAI , and possible also new P-TMSI. When the 
UE has made necessary updates it answers with Network 
Initiated Routing Area Update Complete. 

14 . When receiving new MM system information indicating 
a new Location Area, the UE will, in this case, initiate 
a Location Area update procedure towards the MSC2 . This 
implies that the Location Area update will be performed 
in parallel to the above indicated activities related to 
the SGSN side of the Core Network. 
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UE-GGSN Communication path during the SRNS 
relocation procedure 

Before point (a) , in Fig. 9A, the connection is 
established between UE and GGSN via Source SRNC and 
SGSNl, as shown in Fig. 10 (Fig. 4-28 of 3G TS 23.121 v 
3.1.0) . 

After transmission of the "SRNS relocation commit" 
to the target SRNC (after point (a) in Fig. 9A, the 
source RNC cannot exchange data with the UE because its 
RLC should be frozen after the transmission of the RLC 
sequence numbers to the target RNC. Before the restart 
of the RLC between target SRNC and UE (before point (b) 
in Fig. 9A) , data transfer cannot go on. All downstream 
packets received by the target SRNC during this phase are 
buffered until restart of the RLC between target SRNC and 
UE. 

After point (c) , in Fig. 9A, the connection is 
established between UE and GGSN via Target RNC and SGSN2 . 

Before resource release in source RNC (before T3- 
TUNNEL expiry) , target SRNC may receive downstream packet 
from two paths. Packets remaining on the backbone are 
sent on the "old path" (via SGSNl and RNCl) and forwarded 
by source RNCl to target SRNC2 while packets received by 
the GGSN on its Gi interface are sent on the new path 
(via SGSN2) to target SRNC 2 . 

Fig. 11 shows data paths after the GGSN update 
(after point (c) in Fig. 9A) . 

Fig. 12 shows data paths after the resource release 
in source RNC (after the release response in Fig. 9A) . 

Although the invention has been shown and described 
with respect to a best mode embodiment thereof, it should 
be understood by those skilled in the art that the 
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foregoing and various other changes, omissions and 
additions in the form and detail thereof may be made 
therein without departing from the spirit and scope of 
the invention. 
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CLAIMS 



1. Method of negotiating parameters of an 
optimization algorithm during connection handover of a 
5 mobile station between radio network subsystems, 
comprising the steps of : 

signaling from a source radio network subsystem 
to a core network or to a target radio network subsystem 
that said handover is required; 
10 signaling from the core network or from the 

target radio network subsystem to the source radio 
network subsystem that said handover is to proceed; and 
transmitting said parameters from said source 
radio network subsystem to said target radio network 
15 subsystem directly or via the core network without any 
need for renegotiating said parameters over an air 
interface between said mobile station and said target 
radio network subsystem. 

2 0 2. The method of claim 1, wherein during initial 

establishment of said connection between the mobile 
station and the source radio network subsystem, the 
parameters may include various optional sets of 
parameters, only one of which is accepted by the source 

25 radio network subsystem, said method further comprising 
the step of storing all of said optional sets of 
parameters wherein said step of transmitting said 
parameter includes transmitting all of said optional sets 
of parameters . 
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3 . Mobile telecommunications system including a 
core network (14) connected (lu) to plural interconnected 
(lur) radio network subsystems (11, 12) for communicating 
with a mobile station (10) over an air interface (Uu) , 
5 wherein a first one of said radio network subsystems (11) 
includes a source radio network controller (16) for 
signaling to said core network or to a target radio 
network controller (20) in a second one of said radio 
network subsystems (12) that a handover is required 

10 wherein in response thereto said core network or said 

target radio network subsystem signals the source radio 
network controller that said handover is to proceed, and 
wherein parameters are then transmitted from said source 
radio network controller to said target radio network 

15 controller directly or via the core network without any 
need for renegotiating said parameters over said air 
interface between said mobile station and said target 
radio network controller. 

2 0 4. The system of claim 3, wherein during an 

initial negotiation of said parameters between the mobile 
station and the source radio network controller, said 
parameters include various optional sets of parameters, 
only one of which is accepted by the source radio network 
25 controller, wherein said various optional sets of 
parameters are stored by said source radio network 
controller for transmittal to said target radio network 
controller after said source radio network controller 
signals said target radio network controller that said 

3 0 handover is to proceed. 
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ABSTRACT OF THE DISCLOSURE 

Instead of renegotiating parameters relating to an 
optimization algorithm previously negotiated between a 
5 mobile station and a target radio network subsystem 

during connection handover of the mobile station from a 
source radio network subsystem, prestored parameters are 
transferred instead between the source radio network 
subsystem and the target radio network subsystem either 
10 directly over an existing lur interface or via a core 
network over an lu interface . 
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